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REMARKS 

Applicants have thoroughly considered the Examiner's remarks in the February 20, 2008 
final Office action and claims 1-21 and 23 are presented in the application for further 
examination. By this Amendment B, Applicants amend claims 13,21, and 23. Reconsideration 
of the amended application in view of the following remarks is respectfully requested. 

Claim Objections 

Claims 13 and 21 stand objected to because of the following informalities: claims 13 and 
21 recite the term or limitation "computer storage readable medium." Claims 13 and 21 have 
been amended as suggested by the Examiner, thus the objection should be withdrawn. 

Claim Rejections Under 35 U.S.C. § 112 

Claim 23 stands rejected under 35 U.S.C. § Claims 23 is rejected under 35 U.S.C. 1 12, 
second paragraph, as being indefinite for failing to particularly point out and distinctly claim the 
subject matter which applicant regards as the invention. Claim 23 has been amended to recite 
"determining a state of the client device", therefore, the rejection of claim 23 should be 
withdrawn. 

Claim Rejections Under 35 U.S.C. § 102 

Claim 23 stands rejected under 35 U.S.C. 102(b) as being anticipated by U.S. Pub. No. 
2002/0095454 to Reed et al. (herein after Reed). A claim is anticipated only if each and every 
element as set forth in the claim is disclosed, either expressly or inherently in a single prior art 
reference. Applicants respectfully submit that each and every element as set forth in the recited 
claim is not found, either expressly or inherently in the Reed reference. Thus, Reed does not 
anticipate the claim. 

Reed teaches a system for transferring data, metadata and methods from a provider 
computer to a consumer computer through a communications network. (Reed, Abstract). The 
Examiner asserts that paragraph 291 of Reed teaches not sending the sync notification to the 
client device, if the state of the client device indicates the client device is not in the up-to-date 
state prior to the received notification. Applicants disagree; paragraph 291 of Reed merely 
teaches a method to automate acknowledgements of received communication objects. The 
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provider can cause an acknowledgment message to be returned to the provider program. 

(Reed, page 31, paragraph [0291]). When a consumer program receives a communications 
object instance from a provider program, the consumer program executes the object's receipt 
methods, including the SendAck method which changes the value of the AckFlag attribute to 
TRUE to acknowledge the communications object has been received. (Reed, page 31, 
paragraph [0291]). The provider program periodically executes an AckMonitor method to 
queries for all acknowledgment associations where AckDateTime is equal to or less than NOW 
and AckFlag is FALSE. (Reed, page 31, paragraph [0291]). Those instances meeting this 
criteria represent recipients from whom acknowledgment messages have not been received 
in the allotted interval . (Reed, page 31, paragraph [0291]). And after the retry count 
increments beyond a threshold, Reed teaches further user notification could be triggered, as 
well as other appropriate actions designated by the provider, such as deletion or inactivation of 
the recipient instance. (Reed, page 3 1 , paragraph [0291]). In other words, in paragraph 291, 
Reed merely teaches the sending of and receiving of acknowledgements, not notifications. 
Furthermore, Reed teaches away from the claimed invention because actions are performed in 
response to a retry count, not the state of the device. 

However, Reed teaches that a notification regarding the object is sent to the user 
according to his/her preferences . (Reed, page 21, paragraph [0207]). Examples of notification 
preferences include "having the object displayed immediately, to receive an e-mail about the 
previously presented object, to include a message about the previously presented object in the 
user's notification report (including its size, methods, update intervals, etc.), or any other 
notification action or combination of actions. (Reed, page 21, paragraph [0207]). For example, 
the user may wish to have an object displayed immediately if the user manually selected it as a 
HTTP request from a Web site, but not if it was an object update retrieved automatically via a 
Web HTTP polling request by the consumer program 22, or if it arrived via e-mail. (Reed, page 
21, paragraph [0207]). 

In contrast, claim 23 recites: 

receiving notification that an event of interest has been received; 

determining if a trackingGUID (globally unique identifier) equals a 
syncGUID, wherein the syncGUID is updated after each successful device 
synchronization of the client device and the trackingGUID is the last known 
syncGUID; 



9 



MS#303717.01 (5221) 



determining a state of the client device is not up-to-date when the 
trackingGUID (globally unique identifier) equals the syncGUID, wherein the 
client device has not performed a sync since a prior notification was processed 
and the client device is not in the up-to-date state prior to the received notification; 

determining the state of the client device is up-to-date when the 
trackingGUID (globally unique identifier) does not equal the syncGUID, 
wherein the client device has performed a sync since the prior notification was 
processed and the client device is in the up-to-date state prior to the received 
notification; 

sending the sync notification to the client device, if the state of the 
client device indicates the client device is in the up-to-date state prior to the 
received notification; and 

not sending the sync notification to the client device, if the state of the 
client device indicates the client device is not in the up-to-date state prior to 
the received notification. 

For example, a user turns a mobile phone off for a few hours while in a meeting or out to 
lunch. Suppose during that period of time, twenty-five e-mails are received. The method of 
Reed causes twenty-five separate notifications. Unlike the method taught by Reed, as soon the 
device is turned back on Applicants' invention causes only one sync notification to be received 
and processed. Advantageously, by "not sending the sync notification to the client device, if 
the state of the client device indicates the client device is not in the up-to-date state prior to 
the received notification", the client devices will not receive multiple notifications between 
synchronizations resulting in increased performance and decreased cost by decreasing the 
amount of data transferred to a device. Thus, the user avoids having to choose between not 
receiving a notification as soon as a change occurs after synchronization and receiving a 
notification every time a change occurs as taught by Reed. Thus Reed does anticipate not 
sending the sync notification to the client device; if the state of the client device indicates 
the client device is not in the up-to-date state prior to the received notification as recited in 
claim 23. For at least these reasons, Applicants submit that Reed does not anticipate each and 
every element of claim 23. As such, the rejection of claim 23 should be removed. 

Claim Rejections Under 35 U.S.C. § 103 

Claims 1-10 stand rejected under 35 U.S.C. § 103(a) as being unpatentable over Reed in 
view of U.S. Pub No. 200/20071436 to Border et al. (Border) and further in view of U.S. Pub No. 
2005/0086306 to Lemke (Lemke). 
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Border discloses a system for a proxy architecture. (Border, abstract). As part of the 
system, Border teaches that an expiration time of a timer to be equal to the timeout value of the 
time plus the current system time. (Border, page 22, paragraph [0240]). Additionally, Border 
teaches that on the expiration of the timer, the system makes a check for TCP connection 
timeouts. (Border, page 22, paragraph [0240]). 

Lemke discloses a system for managing the transfer of messages of a network via 
background delivery. (Lemke, abstract). Lemke teaches setting composite bandwidth values 
within an interval. (Lemke, page 8, paragraph [0121]). 

Claims 1-10 

In contrast, claim 1 recites a method to provide a sync notification to a client device 
comprising the steps of: 

receiving notification that an event of interest has been received; 

determining a state of the client device, said state indicating whether or not 
the device has outstanding sync notifications , said state being determined based on a 
trackingGUID and a syncGUID; and 

if the state of the client device indicates that the client device has no outstanding 
sync notifications: 

setting the trackingGUID equal to the syncGUID, wherein the 

syncGUID is updated after each successful device synchronization of the 

client device; 

setting a timeout equal to a current time plus a predetermined value, 
said timeout being the maximum time between sync notifications if the state of 
the client device indicates the client device has at least one outstanding sync 
notification; and 

sending the sync notification to the client device; and 
not sending the sync notification to the client device if the state of the client 
device indicates that the client device has at least one outstanding sync notifications. 



For example, the device is up-to-date when, to the server's knowledge, the device is 
completely in sync with the server with the possible exception of the event which just triggered a 
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sync notification. (Specification, [0027]). The device is pending synchronization when a sync 
notification has been sent to the device telling it to sync with the server, but the device has 
not yet performed synchronization . (Specification, [0027]). The syncGUID for a device is 
updated after each successful device synchronization with the server. (Specification, [0027]). 
And, the syncGUID is used to designate a parameter that provides a representation of the state 
of the device and it provides an indication of whether an event of interest renders the device no 
longer up to date from the perspective of the server or whether an event of interest occurs and 
the server has not been contacted by the device for a certain period of time. (Specification, 



Advantageously, the client devices will not receive multiple notifications between 
synchronization. This results in increased performance and decreased cost by decreasing the 
amount of data transferred to a device. And, unlike the system disclosed by Reed, the user does 
not have to decide on a frequency of notification. Thus, the user avoids the problem of having to 
choose between not receiving a notification as soon as a change occurs after synchronization and 
receiving a notification every time a change occurs. 

Neither Reed, Border or Lemke, alone or in combination, discloses or makes obvious 
determining a state of the client device, said state indicating whether or not the device has 
outstanding sync notifications as recited in claim 1 . Writing for the Supreme Court, Justice 
Anthony Kennedy observed that a patent claim is invalid for obviousness when the invention 
combines familiar elements according to known methods to produce no more than predictable 
results. KSR International Co. v. Teleflex, Inc. U.S., No. 04-1350, 4/30/07. However, in this 
rejection, neither the element of determining a state of the client device nor the result of 
sending the sync notification to the client device, if the state of the client device indicates 
that the client device has no outstanding sync notifications and not sending the sync 
notification to the client device if the state of the client device indicates that the client device 
has at least one outstanding sync notifications is not found in the combined art. 

For at least these reasons, Applicants submit that cited reference, alone or in combination, 
does not teach or make obvious each and every element of claim 1 . As such, the rejection of 
claim 1 should be removed. Additionally, claims 2-10 depending from claim 1 are allowable for 
at least the same reasons as claim 1 . 



[0027]). 
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Claims 11-22 

Claims 11-13 and 17-21 stand rejected under 35 U.S.C. § 103(a) as being unpatentable 
over U.S. Pub. No. 2002/0095454 to Reed et al. (Reed) in view of U.S. Pub No. 2005/0086306 
to Lemke (Lemke). 

Claim 1 1 includes subject matter similar to claim 1 and is allowable for at least the same 
reasons as claim 1. Additionally, claims 12-21 depending from claim 1 1 are allowable for at 
least the same reasons as claim 1 1 . 

Claims 14-16 stand rejected under 35 U.S.C. § 103(a) as being unpatentable over U.S. 
Pub. No. 2002/0095454 to Reed et al. (Reed) in view of U.S. Pub No. 2005/0086306 to Lemke 
(Lemke) and further in view of U.S. Pub No. 200/20071436 to Border et al. (Border). 

Claims 14-16 depending from claim 1 1 are allowable for at least the same reasons as 
claim 1 1 . 
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Conclusion 

Applicants submit that the claims are allowable for at least the reasons set forth herein. 
Applicants thus respectfully submit that claims as presented are in condition for allowance and 
respectfully request favorable reconsideration of this application. 

Although the prior art made of record and not relied upon may be considered pertinent to 
the disclosure, none of these references anticipates or makes obvious the recited aspects of the 
invention. The fact that Applicants may not have specifically traversed any particular assertion 
by the Office should not be construed as indicating Applicants' agreement therewith. 

Applicants wish to expedite prosecution of this application. If the Examiner deems 
the application to not be in condition for allowance, the Examiner is invited and 
encouraged to telephone the undersigned to discuss making an Examiner's amendment to 
place the application in condition for allowance. 

The Commissioner is hereby authorized to charge any deficiency or overpayment of any 
required fee during the entire pendency of this application to Deposit Account No. 19-1345. 



Respectfully submitted, 

/Robert M. Bain/ 

Robert M. Bain, Reg. No. 36,736 

SENNIGER POWERS LLP 

One Metropolitan Square, 16th Floor 

St. Louis, Missouri 63102 

(314) 231-5400 
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